Wireless communication systems are widely known in which base stations (BSs) form “cells” and communicate with terminals (called user equipments or UEs in LTE) within range of the BSs.
In such a system, each BS divides its available bandwidth, i.e. frequency and time resources in a given cell, into individual resource allocations for the user equipments which it serves. The user equipments are generally mobile and therefore may move among the cells, prompting a need for handovers of radio communication links between the base stations of adjacent cells. A user equipment may be in range of (i.e. able to detect signals from) several cells at the same time, but in the simplest case it communicates with one “serving” or “primary” cell.
For assisting understanding of the inventive concepts to be described later, some outline will be given of some of the features of LTE which are of particular relevance to certain embodiments herein. However, it is to be understood that the present invention is not restricted to use in LTE.
Basic LTE Network Topology
The network topology in LTE is illustrated in FIG. 1. As can be seen, each terminal or UE 12 connects over a wireless link via a Uu interface to a base station or eNB 11, and the network of eNBs is referred to as the eUTRAN 10.
Each eNB 11 in turn is connected by a (usually) wired link using an interface called S1 to higher-level or “core network” entities, including a Serving Gateway (S-GW 22), and a Mobility Management Entity (MME 21) for managing the system and sending control signalling to other nodes, particularly eNBs, in the network. In addition, a PDN or Packet Data Network Gateway (P-GW) is present, separately or combined with the S-GW 22, to exchange data packets with any packet data network including the Internet. The core network 20 is called the EPC or Evolved Packet Core.
For assisting understanding of the inventive concepts to be described later, some outline will be given of some specific aspects or features of LTE which are of particular relevance to certain embodiments herein. Further details of the features outlined below are given by the following documents, hereby incorporated by reference:
3GPP TS 36.211: “Evolved Universal Terrestrial Radio Access (E-UTRA); Physical channels and modulation”
3GPP TS 36.212: “Evolved Universal Terrestrial Radio Access (E-UTRA); Multiplexing and channel coding”
3GPP TS 36.213: “Evolved Universal Terrestrial Radio Access (E-UTRA); Physical layer procedures”
3GPP TS 36.321: “Evolved Universal Terrestrial Radio Access (E-UTRA); Medium Access Control (MAC) protocol specification”
Frame Structure and Resource Blocks
In the downlink of an LTE system, in other words the direction of transmission from the base station (eNB) towards the user equipments (UEs), individual OFDM subcarriers or sets of subcarriers are assigned to different user equipments. The result is a multi-access system referred to as OFDMA (Orthogonal Frequency Division Multiple Access). By assigning distinct frequency/time resources to each user equipment in a cell, OFDMA can substantially avoid interference among the users served within a given cell.
The UEs are allocated a specific number of subcarriers for a predetermined amount of time. An amount of resource consisting of a set number of subcarriers and OFDM symbols is referred to as a physical resource block (PRB) in LTE. PRBs thus have both a time and frequency dimension. Allocation of RBs is handled by a scheduling function (scheduler) at the eNB.
Data for transmission on the downlink is organised in OFDMA frames each divided into a number of sub-frames. Various frame types are possible and differ between frequency division duplex (FDD) and time division duplex (TDD) for example. In FDD, transmission and/or reception may occur simultaneously on DL and UL using different carrier frequencies, whilst in TDD downlink and uplink transmissions occur on the same carrier frequency and are separated in time. An FDD frame consists of 10 uplink subframes and 10 downlink subframes occurring simultaneously. In TDD, various allocations of subframes to downlink and uplink are possible, depending on the load conditions. Subframes may consequently be referred to as uplink subframes or downlink subframes.
FIG. 2 shows a generic frame structure for LTE, applicable to the downlink, in which the 10 ms frame is divided into 20 equally sized slots of 0.5 ms. A sub-frame SF consists of two consecutive slots, so one radio frame contains 10 sub-frames. The UEs are allocated, by a scheduling function at the eNB, a specific number of subcarriers for a predetermined amount of time. Such allocations typically apply to each subframe. Resources are allocated to UEs both for downlink and uplink transmission (i.e. for both downlink subframes and uplink subframes).
The transmitted signal in each slot is described by a resource grid of sub-carriers and available OFDM symbols, as shown in FIG. 3. Each element in the resource grid is called a resource element (RE) and each resource element corresponds to one symbol.
For each transmission time interval of 1 ms, a new scheduling decision is taken regarding which UEs are assigned to which time/frequency resources during this transmission time interval, the scheduling being made in units of resource blocks, also called Physical Resource Blocks, PRBs. As shown in FIG. 3, one physical resource block is usually defined as 7 consecutive OFDM symbols in the time domain and 12 consecutive sub-carriers in the frequency domain. Several resource blocks may be allocated to the same UE, and these resource blocks do not have to be contiguous with each other. Scheduling decisions are taken at the eNB, using a scheduling algorithm which takes into account the radio link quality situation of different UEs, the overall interference situation, Quality of Service requirements, service priorities, etc.
FIG. 3 shows that a PRB is composed of multiple resource elements REs of time duration equal to one OFDM symbol and extending over one subcarrier in the frequency domain. In LTE, data and control channels may be transmitted using a subset of the REs in one or more PRBs. PRBs are often considered in pairs, where a PRB pair consists of two PRBs, adjacent in the time domain, and in the same subframe. A unit of resource used in describing control channel transmission is a control channel element or CCE, which consists of a number of Resource Element Groups or REGs.
According to the above mentioned 3GPP TS36.211, section 6.2.4, resource-element groups (REGs) are used for defining the mapping of control channels (see below) to resource elements.
PDCCH
In LTE, several channels for data and control signalling are defined at various levels of abstraction within the system. FIG. 4 shows some of the channels defined in LTE at each of a logical level, transport layer level and physical layer level, and the mappings between them. For present purposes, the downlink channel PDCCH at the physical layer level is of most interest.
On the downlink, user data is carried on the Physical Downlink Shared Channel, PDSCH, which conventionally is distinct from (i.e. does not include) the Physical Downlink Control Channel, PDCCH.
In LTE, both the DL and UL are fully scheduled since the DL and UL traffic channels are dynamically shared channels. This means that PDCCH must provide scheduling information to indicate which users should decode the physical DL shared channel (PDSCH) in each sub-frame and which users are allowed to transmit on the physical UL shared channel (PUSCH) in each sub-frame. PDCCH is used to carry scheduling information—called downlink control information, DCI—from eNBs to individual UEs. Conventionally, one PDCCH message contains one DCI format. This is often intended for one individual UE, but some messages are also broadcast (for example intended for multiple UEs within a cell). Thus PDCCH can also contain information intended for a group of UEs, such as Transmit Power Control (TPC) commands. In addition the PDCCH can be used to configure a semi-persistent schedule (SPS), where the same resources are available on a periodic basis. Below, the terms PDCCH, PDCCH message, DCI and DCI message are used interchangeably unless the context demands otherwise.
Reference was made earlier to CCEs and REGs. PDCCH is transmitted on an aggregation of one or several consecutive CCEs, where a control channel element corresponds to 9 REGs. Thus, at a minimum, PDCCH may occupy a single CCE; the number of CCEs employed is referred to as the “aggregation level” (1, 2, 4 or 8). The number of resource-element groups not assigned to PCFICH or PHICH is NREG. The CCEs available in the system are numbered from 0 to NCCE−1, where NCCE=└NREG/┘
Although the REGs used for PDCCH may be initially adjacent, an interleaver is applied to spread the REGs across the frequency domain. Therefore, PDCCH will typically be transmitted using a set of REGs spread across the whole system bandwidth and all the symbols reserved for PDCCH. In LTE up to four OFDM symbols may be reserved for PDCCH at the start of the first PRB of a PRB pair.
A cyclic redundancy check (CRC) is used for error detection of the DCI. The entire PDCCH payload is used to calculate a set of CRC parity bits, which are then appended to the end of the PDCCH payload.
As multiple PDCCHs relevant to different UEs can be present in one sub-frame, the CRC is also used to specify which UE a PDCCH is relevant to. This is done by scrambling the CRC parity bits with a Radio Network Temporary Identifier (RNTI) of the UE. The RNTI is thus associated with the PDCCH and the DCI. Various kinds or RNTI are defined in the 3GPP documents cited earlier. Depending on the purpose of the DCI message, different DCI formats are defined. The DCI formats include:
Format 0 for transmission of uplink shared channel (UL-SCH) allocation
Format 1 for transmission of DL-SCH allocation for Single Input Multiple Output (SIMO) operation
Format 1A for compact transmission of DL-SCH allocation for SIMO operation or allocating a dedicated preamble signature to a UE for the RACH procedure
Format 3 and format 3A for transmission of TPC command for an uplink channel.
The Table below, taken from the above mentioned 3GPP TS36.211, section 6.8.1, shows the PDCCH formats supported in LTE.
Number ofCCEsNumber ofPDCCH(aggregationresource-Number offormatlevel)element groupsPDCCH bits01972121814424362883872576
A PDCCH consisting of n consecutive CCEs may only start on a CCE fulfilling i mod n=0 where i is the CCE number, and multiple PDCCHs can be transmitted in a subframe.
Thus, the DCI format to be used depends on the purpose of the control message. For example, DCI Format 1 is used for the assignment of a downlink shared channel resource when no spatial multiplexing is used (i.e. the scheduling information is provided for one code word transmitted using one spatial layer only). The information provided enables the UE to identify the resources, where to receive the PDSCH in that sub-frame, and how to decode it. Besides the resource block assignment, this also includes information on the modulation and coding scheme and on the hybrid ARQ protocol used to manage retransmission of non-received data.
DCI Formats 3 and 3A carry multiple power control bits representing multiple power control commands, each power control command being intended for a different UE. The main application of interest for Formats 3 and 3A is to support SPS in the uplink (since UE specific PDCCH DCI formats to carry power control commands are not then required). Since, as already mentioned, multiple UEs can be scheduled within the same sub-frame, conventionally therefore multiple DCI messages are sent using multiple PDCCHs.
Without any additional restrictions a UE would need to check all possible combinations of PDCCH locations, PDCCH formats, and DCI formats and act on those message with correct CRCs (taking into account that the CRC is scrambled with a RNTI). This is called “blind decoding”. In UESS the number of blind decoding candidates for aggregation levels 1, 2, 4, and 8 are 6, 6, 2 and 2 respectively. In the CSS only aggregation levels 4 and 8 are used and the numbers of candidates are 4 and 2 respectively.
To reduce the required amount of blind decoding of all the possible combinations, for each UE a limited set of CCE locations is defined where a PDCCH may be placed. The set of CCE locations in which the UE may find its PDCCH is called the “search space”, and in LTE, separate UE-specific search spaces (UESSS) and common search spaces (CSS) are defined. The CSS is typically used for DCI messages intended for more than one UE, while the UESSS is typically used for DCI messages intended for a single UE.
These locations are also referred to below as “candidate locations” or simply “candidates”. For understanding certain embodiments to be described, it is important to note that there is a distinction between “candidate locations” and the actual location which the eNB uses for the DCI message. Each candidate corresponds to one blind decoding attempt in a given location by the UE, as distinct from the selection of a location (from the available candidates) by the eNB for actual transmission of a DCI message.
In general a “location” in the context of PDCCH can be understood to correspond to a set of resource elements in which a DCI message may be transmitted, and which can also correspond to a set of REGs and a set of CCES. The amount of resource in REs/REGs/CCEs used, or assumed to be used, for transmission of a DCI message can be understood to correspond to the “size” of a candidate.
The relationship between aggregation level, size and number of PDCCH candidates is given in the following Table, taken from 3GPP TS36.213 section 9.1.1.
TABLE 9.1.1-1PDCCH candidates monitored by a UE.Number ofPDCCHSearch space Sk(L)candidatesTypeAggregation level LSize [in CCEs]M(L)UE-166specific21264828162Common41648162
It may be helpful to quote from the PDCCH Assignment Procedure as set out in 3GPP TS36.213, section 9.21.1 as follows:
“The control region of each serving cell consists of a set of CCEs, numbered from 0 to NCCE,k−1 according to Section 6.8.1 in [3], where NCCE,k is the total number of CCEs in the control region of subframe k. The UE shall monitor a set of PDCCH candidates on one or more activated serving cells as configured by higher layer signalling for control information in every non-DRX subframe, where monitoring implies attempting to decode each of the PDCCHs in the set according to all the monitored DCI formats.
The set of PDCCH candidates to monitor are defined in terms of search spaces, where a search space Sk(L) at aggregation level L∈{1,2,4,8} is defined by a set of PDCCH candidates. For each serving cell on which PDCCH is monitored, the CCEs corresponding to PDCCH candidate m of the search space Sk(L) are given by:L{(Yk+m′)mod └NCCE,k/L┘}+i  Expression 2.1
where i=0,L, L−1
For the common search spaces, Yk is set to 0 for the two aggregation levels L=4 and L=8.
For the UE-specific search space Sk(L) at aggregation level L, the variable Yk is defined by:Yk=(A·Yk−1)mod D  Expression 2.2
where Y−1=nRNTI≠0, A=39827, D=65537 and k=└ns/2┘, ns is the slot number within a radio frame. The RNTI value used for nRNTI is defined in section 7.1 in downlink and section 8 in uplink.
For the common search space m′=m. For the UE specific search space, for the serving cell on which PDCCH is monitored, if the monitoring UE is configured with carrier indicator field then m′=m+M(L)·nCI where nCI is the carrier indicator field value, else if the monitoring UE is not configured with carrier indicator field then m′=m, where m=0, L,M(L)−1. M(L) is the number of PDCCH candidates to monitor in the given search space.”
As will be apparent, Expression 2.2 provides a pseudo-random function with a different result for each subframe k and for each UE (owing to the use of the UE's RNTI). Consequently Expression 2.1 yields a pseudo-random selection of a set of L successive CCE indices (incrementing by one each time), identifying the CCEs corresponding to the candidate locations.
To summarise, in any given subframe a DCI message for a given UE may be transmitted in one of several candidate locations which are determined pseudo-randomly. The algorithm for generating these candidate locations (or search space) gives different results for different UEs (based on the UE identity) and different subframes. For PDCCH, for simplicity the search space locations are generated using the same pseudo-random number as is used to generate the starting point (in terms of the first CCE which could be used) for the first candidate for different aggregation levels, but this typically results in the use of different CCEs per aggregation level. For a given aggregation level the search space consists of a set of adjacent locations for each successive candidate at least before any interleaving is applied. This scheme does have the advantage that UEs which may have the same search space locations (candidate locations) in one subframe will most likely have different locations in the next subframe, which removes the risk that these UEs would persistently block each other from using the PDCCH resources.
The same algorithm is expected to be used by both the network side (eNB) and the terminal. For a given subframe, the terminal calculates the set of candidate locations (resources) in which it should attempt reception of a DCI message (by blind decoding). This is the “search space” for a given UE. If the eNB wishes to send a DCI message to that UE in a particular subframe, the eNB will typically do the same calculation in order to determine In which locations it will be possible to transmit the DCI message and have it received by the UE (or at least where the UE will attempt reception). Both the eNB and UE are expected to perform the pseudo-random selection for all the candidates.
The eNB then chooses one of those candidate locations for the actual DCI message transmission. This is determined in dependence on which other UEs the eNB also wishes to send DCI messages to. Given that the set of candidate locations for each UE will typically be different, for any given UE some of the locations could also be the same as candidates for other UEs. Normally the eNB will only be able to transmit one DCI message in a given candidate location and consequently, once a given candidate location has been employed once by the eNB it is “used up” for that subframe. Therefore it is possible that while the total number of available locations could appear sufficient for the number of DCI messages to be sent in given subframe, overlaps in the search spaces between different UEs will reduce the number of possible DCI messages which could be sent, and “blocking” could occur.
If the set of candidates is small, and In a given subframe all those candidates for one UE are all “blocked” by DCI messages for other UEs, then the probability of blocking also occurring in the next subframe Is reduced if the sets of candidates are changed from subframe to subframe. This aspect Is likely to be more significant if there is a need to send more than one DCI message to a given UE in a subframe or UEs need to be sent multiple DCI message in successive subframes, or the UE-specific search space happens to overlap with the common search space (which is in a fixed location, and can be heavily loaded). Incidentally, the LTE specifications do not require that the eNB calculates all the candidate locations for a given UE, but this will be expected in a good implementation. It would be possible to reduce the blocking probability by increasing the amount of resource in which PDCCH can be transmitted (in other words to increase NCCE, k in expression 2.1); however, this would reduce the resources available to send data using PDSCH.
ePDCCH
A new control channel design (ePDCCH) is under discussion in 3GPP for LTE. This will transmit DCI messages in the same resources as currently reserved for downlink data (PDSCH). The ePDCCH will support a UESSS, but it is open whether a CSS will be specified for ePDCCH.
A possible motivation for using a CSS on ePDCCH is to reduce congestion on PDCCH, for example if there are more urgent DCI messages to be sent than can be accommodated within one subframe, then these could be sent on ePDCCH, and by using CSS any UE can be addressed.
ePDCCH may be transmitted in either a frequency-localized or a frequency-distributed manner depending on the requirements of the system. Localized transmission would be appropriate if the channel/interference properties are frequency selective, in which case it may be possible to transmit DCI messages in a favourable location in the frequency domain for a given UE. In other cases, for example if no frequency selective channel information is available at the eNB, distributed transmission (corresponding to the manner of transmission of PDCCH) would be appropriate.
The above explanation of PDCCH referred to the possibility of “blocking” between DCI messages intended for different UEs. For ePDCCH the eNB will also want to take into account knowledge of the channel conditions for differed parts of the spectrum in selecting which candidate location to use for a given UE. If the eNB wishes to use only “good” parts of the spectrum (for example high received SNR for that UE), the probability of blocking is likely to be increased since the number of suitable candidate locations will be reduced.
The design for distributed ePDCCH can be quite similar to PDCCH i.e. some resources are configured for distributed ePDCCH, the UE has a blind decoding search space within those resources, and a given DCI message will use a set of resource elements are spread across the frequency domain. By analogy with PDCCH, resources used for ePDCCH may be expressed in units of cCCE (corresponding to CCE) and eREG (corresponding to REG). These units eCCE and eREG may, but need not, have the same size in terms of REs or may differ in terms of mapping to physical resources. It is assumed, however, that 4 eCCEs will fit in one PRB pair. For localised ePDCCH the exact size of an eCCE or eREG is not of major importance for the purpose of describing certain embodiments.
More details and current assumptions in 3GPP on localized ePDCCH are as follows:                A DCI message consists of 1,2,4 or 8 eCCEs. This could be defined in terms of eREGs (like for distributed ePDDCH), and 1 eCCE would then be equivalent to a number of eREGs (e.g. 4).        Up to 4 eCCEs can be transmitted in one PRB pair        
More details and current assumptions in 3GPP on distributed ePDCCH are as follows:                A PRB pair is divided in to a number of eREGs (e.g. 16)        A DCI message consists of 4, 8, 16, or 32 eREGs. This could be equivalent to 1, 2, 4 or 8 eCCEs        For frequency diversity the eREGs of a DCI message is are transmitted across multiple PRB pairs (e.g. 4 PRB pairs). Then a PRB pair could contain 1, 2, 4 or 8 eREGs from one DCI message        
Some of the particular design requirements for localised ePDCCH are:                DCI messages can be transmitted in frequency domain locations with suitable channel and interference conditions for each terminal i.e. there are candidate locations in across the frequency domain        the terminal does not need to blind decode too many candidates (e.g. comparable with PDCCH)        the resources occupied by control messages are used efficiently (i.e. it is desirable that DCI messages which do not occupy a whole PRB can be multiplexed together in the same PRB, rather than being placed in separate PRBs)        the possibility of sharing resources with distributed ePDCCH (in other words sending DCI both in localised ePDCCH and distributed ePDCCH in the same subframe, at least in different PRB pairs)        use of resources for ePDCCH should have minimal impact on PDSCH        the probability is minimized of a control message for one terminal blocking transmission of a message to another terminal in the same resource        the probability of persistent blocking from subframe to subframe should be minimized        simple implementation for both network and terminals.        
These requirements for localized ePDCCH are not so easy to satisfy. For example, current proposals so far in 3GPP RANI have not been very detailed and seem to assume that a single set of resources (in terms of PRBs) would be configured to apply for all the DCI message candidates at any aggregation levels. Certain embodiments herein proposes a search space design which allows these requirements to be met.